Cream of the Crop 26/Cream of the Crop 26.iso/bbs/fnewse23.zip/FIDO1423.NWS

Text File | 1997-06-09 | 101KB | 2,195 lines

     F I D O N E W S --       Volume 14, Number 23          9 June 1997
     +----------------------------+-----------------------------------------+
     |  The newsletter of the     |   ISSN 1198-4589 Published by:          |
     |    FidoNet community       |   "FidoNews"                            |
     |          _                 |        1-904-409-7040    [1:1/23]       |
     |         /  \               |                                         |
     |        /|oo \              |                                         |
     |       (_|  /_)             |                                         |
     |        _`@/_ \    _        |                                         |
     |       |     | \   \\       |   Editor:                               |
     |       | (*) |  \   ))      |        Christopher Baker  1:18/14       |
     |       |__U__| /  \//       |                                         |
     |        _//|| _\   /        |                                         |
     |       (_/(_|(____/         |                                         |
     |             (jm)           |     Newspapers should have no friends.  |
     |                            |                    -- JOSEPH PULITZER   |
     +----------------------------+-----------------------------------------+
     |               Submission address: FidoNews Editor 1:1/23             |
     +----------------------------------------------------------------------+
     |  MORE addresses:                                                     |
     |                                                                      |
     |    submissions=> [e-mail]                                |
     +----------------------------------------------------------------------+
     |    For  information,   copyrights,   article   submissions,          |
     |    obtaining copies of FidoNews or the internet gateway FAQ          |
     |    please refer to the end of this file.                             |
     +----------------------------------------------------------------------+


                    IT'S ONLY LAME WITH AN F


                        Table of Contents
     1. EDITORIAL  ................................................  1
        What would it take to get YOU to submit something?  .......  1
     2. LETTERS TO THE EDITOR  ....................................  2
        To Compress Mail or Not to Compress Mail?  ................  2
     3. ARTICLES  .................................................  4
        FidoNet Via Internet Hubs  ................................  4
        Some thoughts on a possible future direction for Fidone  ..  4
        SILLYSEASON Echo forming  .................................  6
        Why I bother  .............................................  7
     4. COLUMNS  ..................................................  9
        Lock and Load: Guerilla Marketing for BBSes  ..............  9
     5. GETTING TECHNICAL  ........................................ 11
        FSC-0080 - Describing FidoNet with layered model  ......... 11
        FSC-0081 - A TYPE-3 Packet proposal  ...................... 13
     6. COORDINATORS CORNER  ...................................... 28
        Nodelist-statistics as seen from Zone-2 for day 157  ...... 28
     7. NET HUMOR  ................................................ 29
        Nevermore?  ............................................... 29
     8. NOTICES  .................................................. 31
        Future History  ........................................... 31
     9. FIDONET SOFTWARE LISTING  ................................. 32
        Latest Greatest Software Versions  ........................ 32
     10. FIDONEWS PUBLIC-KEY  ..................................... 36
        FidoNews PGP public-key listing  .......................... 36
     And more!
     FIDONEWS 14-23               Page 1                    9 Jun 1997


     =================================================================
                                 EDITORIAL
     =================================================================


     What? No urge to write something for FidoNews? You don't have to do a
     formal article or column. You can just send in something via Netmail.
     You can pick something new or forward something of yours from an Echo
     or some other forum.

     It's your newsletter.

     C.B.



     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 2                    9 Jun 1997


     =================================================================
                           LETTERS TO THE EDITOR
     =================================================================


     [This wasn't a Letter to the Editor, but it should have been. Folks
      should not be sending compressed mail to strangers. It adds an extra
      step when receiving mail from unsecured sources among other
      concerns. Unless you're sending a ton of mail, why bother?] Ed.

     --- Following message extracted from FTSC_PUBLIC @ 1:18/14 ---
         By Christopher Baker on Thu Jun 05 15:17:35 1997

     From: Lisa Gronke
     To: All
     Date: 03 Jun 97  06:45:02
     Subj: ARC

     * Original Area: PDX.SYSOP
     * Original To  : Phil McCloud (1:105/61)

     The gospel says you should use either use ARC or no compression when
     sending to strangers.

     The reality is that you're more likely to run into someone who can't
     unARC than someone who can't unZIP.

     There is a networking precept that says, "Be liberal in what you
     accept; be conservative in what you send."

     As long as a sysop understands the landscape, there shouldn't be much
     of a problem either way.

     The biggest problem is passing around configuration files with ZIP
     configured as the default. That breeds new sysops who can't unARC and
     don't even know that they should be able to.

     I recommend ARC as the default, but encourage everyone to explicitly
     address the archiver issue at the time an echomail link is
     established. Alternatively, if you have ZIP as your default, the first
     interchange with a stranger should ask if it is OK.

     And for gawds sake, don't get into a policy pissing contest over the
     issue.

     > I believe some form of .ZIP can be compiled for any platform,
     > however none has ever changed the 'standard'.

     ZIP is very difficult to implement on 8-bit, 64K RAM systems. The
     lookup tables are too big to be kept in RAM. But 8-bit FidoNet systems
     are becoming as rare as ivory billed woodpeckers.

     No one has ever changed the 'standard' (which, btw, is durned
     difficult to find in the FTSC documents), but almost everyone has
     managed to minimize the effect. Other than the nodediff, ftsc and
     policy documents, nothing of any size is sent ARCed. The amount of
     FIDONEWS 14-23               Page 3                    9 Jun 1997


     bandwidth actually lost in ARC transfers is probably less than the
     bandwidth that will be used in arguing about what the replacement
     should be <g>.

     A more cogent argument for the future is that zip/unzip are widely
     available in the unix world, whereas arc is not. I have three unix
     shell accounts. All have zip/unzip. None of them has arc. One has
     lharc. Oh, I'm sure that I can find unix arc source somewhere and
     compile it, but that's a lot of trouble if all I want to do is read
     policy4.arc from ftp.paonline.com.

     Incidentally, the "ARC" issue is a FidoNet (the network) issue, not a
     FidoNet (technology) issue. FTN OtherNets could have a different
     archiver policy.

      Origin: EastSide Data Services (1:105/61)

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 4                    9 Jun 1997


     =================================================================
                                 ARTICLES
     =================================================================


     Fidonet Via Internet Hubs

     Speed|Node#      |Operator          | Facilities        | Basic Rate
     -----+-----------+------------------+-------------------+-----------
     T1   |1:270/101  |George Peace      | FTP               | $30mo.
     T1   |1:396/1    |John Souvestre    | FTP               | $25mo.
     T1   |1:12/12    |Ken Wilson        | FTP               | $24mo.
     T1   |1:140/12   |Bob Seaborn       | FTP, Transx       | $5/$20
     64k  |1:124/7008 |Ben Hamilton      | FTP, VFOS, Transx | $20mo.
     56k  |1:13/25    |Jim Balcom        | FTP               | $20mo.
     33.6 |1:2604/104 |Jim Mclaughlin    | FTP, VFOS, UUEMAIL| $1mo.
     33.6 |1:2624/306 |D. Calafrancesco  | VFOS              | $15yr.
     33.6 |1:281/169  |Brian Greenstreet | FTP               | $2mo.
     28.8 |1:330/204  |Patrick Rosenheim | Transx            | $25yr.

     --
     compiled by Cindy Ingersoll, 1:2623/71, [phone],
     [e-mail] Posted on the 1st of every month in FN_SYSOP,
     R13SYSOP and Fidonews.
     ---


     -----------------------------------------------------------------


     Some thoughts on a possible future direction for FidoNet:
     by Ron Dwight
     2:220/22


         I have been giving consideration lately to a future direction in
     which Fidonet could go and the following is offered for your
     consideration:

     ..  Fidonet is a vastly different medium than the internet and should
     not be swallowed by it.  Fidonet should retain it's current character,
     freedom and flexibility.

     ..  FidoNet nodes need the speed and reduced cost of internet access,
     to communicate, this is why such things as Vmodem are being written.

     ..  The FidoNet nodelist appears to be the largest single obstacle
     standing in the way of major changes to Fidonet methodology and either
     the nodelist can be changed to accommodate the new methods or
     alternative methods can be devised which make use of the current
     nodelist.

               What I am going to propose here, is a method of using the
     current nodelist, with almost no changes and yet allow those nodes
     which require access to internet transport, to obtain it quickly and
     easily.
     FIDONEWS 14-23               Page 5                    9 Jun 1997


               The basic concept revolves around the actual method of
     operation of the internet itself to satisfy the needs of Fidonet
     nodes.  Whenever a connection is made, using a web browser, the
     address which you are seeking, http://.... is sent to a Network Access
     Point computer which translates that name into a TCP/IP address.  This
     is sent back to your browser which then uses it to reach the
     destination computer on the internet.

               What I propose for Fidonet, is something very similar which
     will allow us to maintain the current nodelist format and content and
     yet obtain full access to internet capable systems willing to
     accept callers running Vmodem, Binkd or something similar..

     1)  A computer, or computers, serve as Fidonet Internet Access Points.
         This would best be provided by a reliable system owned and
         operated by a large corporation.  To that end we would perhaps
         need to obtain a sponsor, IBM would do nicely, so would US
         Robotics, to provide access to an internet server to act as the
         Fidonet Name Information Center.  The load on this machine would
         not be great, but a little software would need to be written for
         it.

     2)  We then write a series of specifications for software which would
         use this service to access other Fidonet nodes via the internet.
         Part of this software specification would be something like:

         ..  All internet capable nodes would be flagged in the nodelist
     with a single flag to indicate internet capability.  The flag could
     be, for example: INET or something similar and the flag would indicate
     ONLY that the system was connected to the internet and was capable of
     accepting FidoNet callers.  No other information would be carried in
     the nodelist and the nodelist entry could be used to indicate a normal
     PSTN node as well as an internet capable one.

         ..  Mailers wishing to access an internet capable node must send a
     message, containing ONLY the FidoNet node number
     (Zone:Net/Node.point), over the internet to the FidoNet Name
     Information Center.  The reply from that server would be a message
     containing the capabilities of that node which could then be used to
     establish (or refuse) a session.  The time overhead for such a service
     would be a matter of milliseconds under normal conditions and would
     not add significantly to the length of a session.

         ..  Mailer software, in order to reduce the number of transactions
     to the Name Information Center, would check if the information is
     locally available for the called number and use that if it was, say,
     less than 7 days old.  In other words if the system had been called
     within the last 7 days, it is expected that the same session
     parameters can be used without requesting them again from the Name
     Information Center.

     3)  The information contained, and updated, on the Name Information
         Center would be such things as:

         ..  Transport capability
         ..  Open hours
     FIDONEWS 14-23               Page 6                    9 Jun 1997


         ..  Protocol availability

               In other words, all the stuff that folks are trying to cram
     into the nodelist now.  It could be in IEMSI format or similar.

               A Fidonet node, ZC?/IC? or designated SysOp, would be
     responsible for ensuring that the Name Information Center was properly
     updated and functional.

               This is only the basic outline of a concept which could be
     used to enhance Fidonet capability.  I believe the sponsorship would
     be easy to obtain as the load on the Name Information Center machine
     would be very light as long as the mailers obeyed reasonable rules as
     to access.  More important would be laying down the rules and
     mechanisms for the software to take advantage of the capabilities
     offered.  Obviously a lot of technical detail needs to be worked out,
     but I believe this could be used as a basis to move FidoNet into a
     closer cooperation with the internet to our mutual advantage.

               Someone is going to object that using a single Name
     Information Center gives the entire system a central weakness.  In
     answer to that I would reply that:

     ..  Most of the entire WORLDWIDE internet services rely on only a few
     such centers.

     ..  There is no reason why more than one machine could not be used and
     that these could be indicated in the nodelist, perhaps as comment
     lines, which mailer software can locate.  Of course the more Name
     Information Centers which are created, the more difficult it becomes
     to keep them updated.

               This mini-article is intended as a START.  Andy, Jo, Arjen
     and other developers, it's up to people like you to carry it further
     and make it become a reality.

     -----------------------------------------------------------------


     SILLYSEASON Echo forming
     Fredric L. Rice ([e-mail])
     The Skeptic Tank - 1:102/890.0
     [phone] 24hrs N81

     A new FidoNet echo -- tag named "SILLYSEASON" -- is forming and I'm
     soliciting participation.  The forum will discuss the "Millennium"
     television series yet will also cover the broad spectrum of phenomena
     from which the series draws upon for its subject matter.

     The so-called "Millennium lunacy" phenomena has been commented upon
     and researched in growing frequency this last decade -- and for
     obvious reasons:  The year 2,000 is only three years away.  The
     phenomena labels the cyclic rise and fall of destructive behavior and
     beliefs plotted against the year number; yet it has nothing to do with
     numerology.  It's a matter of the human psychology behind how humans
     contrive notions of significance when there are none.  The phenomena
     FIDONEWS 14-23               Page 7                    9 Jun 1997


     is also called the "silly season" and has been the subject of several
     books and magazine articles.

     Even though the contemporary calendar is a hodge podge of badly formed
     months, weeks, and days, societies ever since the contemporary
     calendar was widely adopted have placed great significance to the year
     number whenever a new decade, century, or millennium comes along.
     Though the year numbers aren't predicated upon any meaningful event or
     indicate any meaningful demarcation, when a year number ends with a
     zero, a large portion of the so-called "Westernized societies" feel
     inclined to believe any damn silly thing and to "prophecy" much
     disaster.  Sadly, many such believers work hard to bring about their
     images of doom and destruction in self-fulfilling prophecy.  We
     observe the results of such beliefs in our newspapers and on
     television news reports.

     For a link to the forum, contact me and I'll set it up.  I suspect
     that this will be a fairly low-volume forum except for times
     immediately following some Millennium lunacy --such as repeats of the
     "Heaven's Gate" mass suicides which are expected and the violent
     activities of self-proclaimed "militias."

     -----------------------------------------------------------------


     Why I bother
     by Troy H. Cheek (1:362/708.4)

     Some say Fidonet is dead.  Obviously, since I'm writing this, and
     you're reading it, and it went through Fidonet, then Fidonet isn't
     dead.  As long as Fidonet isn't dead, it will require people to run
     BBS's, maintain nodelists, move messages, and moderate echoes.  People
     who catch a lot of flak and get very little praise, but people who are
     required nonetheless.

     I've moderated a few Fidonet echomail conferences over the years for
     various reasons.  The ones I moderate right now, however, have exactly
     one thing in common:  They were abandoned without notice by their
     previous moderators.

     I took over echoes which were "dead" or "dying".  You want to hear
     something funny?  All of them are still active and still on the
     backbone.  Had I not taken over, it's possible some of these echoes
     would no longer exist.  But they would not have died because of lack
     of interest of the end users; they would have died because nobody with
     the proper knowledge bothered to update an echolist entry.

     In my mind, there's no doubt that the eventual demise of Fidonet will
     _not_ be because there are no longer any end users (lured away by the
     promise of the Internet and other factors), but because the people who
     do the vital jobs of Fidonet will give them up under the mistaken
     impression that they are no longer needed.

     Back in the early Fidonet days, the stand-alone BBS was declared dead.
     After all, what single BBS could possibly compete with a nation-wide
     network?  And, hearing this solemn announcement that they were dead,
     FIDONEWS 14-23               Page 8                    9 Jun 1997


     BBS's closed shop or joined Fidonet.  A funny thing happened on the
     way to the funeral, though.  Some of the BBS's didn't listen and
     continued to operate for as long as they still had callers.  Some
     operated for years.  A few are _still_ operating to this day. And I've
     been known to call a few every now and then.

     Fidonet has been declared dead, killed by the Internet.  In spite of
     being dead, there are still a lot of people using it daily.  So,
     should we close up shop, forcing all these users to find other means
     of communication?  Or maybe, just maybe, should we keep the doors open
     until the message packets actually stop coming in?

     By all means hook into the Internet!  Learn about the World Wide Web
     and news services and electronic mail!  Make new friends!  Discover
     new sources of knowledge!  But since you can do all these things
     without giving up Fidonet, why do so many people demand we do exactly
     that?  Are they afraid that if we don't take their word that Fidonet
     is dead, instead of waiting for the mail packets to actually quit
     coming in, that it just might take years or even decades before
     Fidonet really ceases to exist?

     As long as I still have access to Fidonet, and as long as there are
     still echoes that interest me, I'll keep posting messages.  And as
     long some of these echoes need somebody to send in echolist entry
     updates and perform the various administrivia functions, I'll still be
     a moderator.

     Troy H. Cheek, VID_GAME Echo Moderator (among others)
     --
     |Fidonet:  Troy H. Cheek 1:362/708.4
     |Internet: 362-708-4![e-mail]
     |
     | Standard disclaimer: The views of this user are strictly his own.
     | River Canyon Rd. BBS <=> Chattanooga OnLine!  Gateway to the World.

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 9                    9 Jun 1997


     =================================================================
                                  COLUMNS
     =================================================================


     Lock and Load: Guerilla Marketing for BBSes
     (A Parenthetical Column) (Robert Parson) (1:3822/1)

     Every month, a major owner shuts down operations.  More operations are
     rumored to be on the brink of going under.  Everyone moans about the
     state of the industry.  "The end is near!"

     Sounds familiar, doesn't it?  Sure sounds like BBSes.  But it isn't.
     This is newspaper.

     True, the total number of newspapers is down, as is total circulation.
     But revenues are at an all time high.  That's because they maximize
     their audience.  That's consultantspeak for targeting the readership.
     Do you really think they created "Food" sections solely because it
     would be a nice thing for the reader?  No.  They were created as a
     showcase for grocery ads.

     (Printed newspapers will never die, as some people have predicted, but
     that's another column for another time)

     BBSes can learn an important lesson here.  This doesn't mean everyone
     should go out and create big "Food" areas on their BBSes (although
     we'll get to that shortly).  However, you can focus some of your
     marketing on specific areas of your BBS.

     Many of you have already experienced success with Genealogy areas or
     possibly even dedicating your BBS to Genealogical research.  Some of
     you look at gaming or chatting to draw in callers.  But there are
     plenty of other topics that are ripe for the pickin'.

     Let's get back that "Food" section (this is going to be in a rather
     circular fashion, so hang with me.)

     Most BBSes have their messages bases numbered in some way or another.
     In many cases they are also alphabetized.  But for the most part, they
     are not organized in any particular way.

     Pull together a text file or a bulletin of some sort that puts the
     message bases into topic order.  Your callers can download this file
     or bulletin, do a search for "FOOD" and there will be a list of the
     message areas that are food-related.  You could also include a few
     lines that will point them to files available on your BBS that are
     food-related (such as "Search the file section for 'meal' and/or
     'recipe'!")

     While this doesn't create quite the same atmosphere as a "Food"
     section in the newspaper, it gives your callers a fairly easy to
     use index of what to look for when they are setting up their mail
     readers. (Sure, they can do a word search using the echo list you have
     available now, but this way they'll just have to do one search instead
     of a bunch.)
     FIDONEWS 14-23               Page 10                   9 Jun 1997


     This will also give you a more specific idea of where everything is at
     when you do any sort of outside promotions.  For instance, you can
     declare "Food Month" on your BBS.  You can highlight the food message
     bases and files in bulletins, local message areas, printed materials,
     in a speech to the local culinary society, on a table at the county
     fair, maybe even enter the local chili cookoff (using a recipe found
     on your BBS, of course).

     You can easily create and promote other "virtual sections" as well.
     But as I keep saying, you have to do more than leave a message on
     other BBSes saying "Come look at my Food Section.  Think "out of the
     box."  That's Bobspeak for get "out of the house."  At the very least,
     you'll get a tan.

                   But wait!  There's more!

     Steve Prado, the Sysop of my Friendly Neighborhood BBS, Jackalope
     Junction (1:3822/1) this past week was a guest on KWHN-AM Fort Smith,
     AR talking about BBSes and International BBS Week.

     The tone of the interview was positive.  Steve was able to pass along
     some good information, not just about his BBS but others in town and
     even a bit about Fidonet.  (By the way, he adapted the sample news
     release I wrote a few weeks back and sent it to the radio station.
     For full disclosure:  I happen to work there and did help set up the
     interview.  But he did the hard work)

     Good job, Steve!


     Robert Parson

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 11                   9 Jun 1997


     =================================================================
                             GETTING TECHNICAL
     =================================================================


     [This is part of the continuing FidoNet History series publishing the
      FTSC Standards and Proposal documents. FSC-0079 {RTF} is skipped due
      to its length {60K}. These docs have been reformatted to 70 columns
      where required and any tables may be askew as a result. High ASCII
      characters have been removed or replaced. Node numbers and telephone
      numbers may be out of date.] Ed.


       | Document: FSC-0080
       | Version:  001
       | Date:     01 Mar 1995
       |
       | Mikael Stoldal, 2:201/337

                       Describing FidoNet with a layered model
                          Mikael Stoldal, 2:201/337@FidoNet

     Introduction
     ============
     FTS-1 tries to describe FidoNet with the OSI model, but I don't think
     that description is any good.

     I have tried to make a better description of FidoNet with the OSI
     model, but without success. I don't think that's possible.

     Instead I made my own layered model, inspired from OSI. I use seven
     layers with the same name as in OSI, but with Session and Transport
     swapped.

     Why this model?
     ===============
     The main goal with this model is to make FidoNet more flexible make it
     easier to change into newer and better protocols and data structures.

     It should be possible to change one layer without affecting the
     others.

     Description of the layers
     =========================

     Physical layer
     --------------
     The telephone network (PSTN).

     Link layer
     ----------
     Modem with protocols like V.22 and V.32. This layer also include real-
     time error correction (V.42, MNP4) and data compression (V.42bis,
     MNP5).

     Serial communication hardware (UART).
     FIDONEWS 14-23               Page 12                   9 Jun 1997


     Network layer
     -------------
     Serial communications drivers (FOSSIL) and file transfer protocols
     (Zmodem etc). Note that this layer can be divided into two sub-layers,
     the file transfer protocol on top on the serial communication driver;
     but upper layers can interact with the serial communication driver
     directly.

     Session layer
     -------------
     Session handshake protocols (YooHoo, EMSI) implemented in mailers.
     This layer can reliably send files directly between two systems. It
     doesn't perform any routing. It doesn't know about NetMail, EchoMail
     etc.

     The upper layers uses logical addresses (node numbers), this layer
     performs address resolution (often by using a nodelist) to obtain the
     physical address (telephone number) necessary to establish a
     connection.

     The upper layers can tell if a file should be sent immediately, when
     appropriate or be placed on hold.

     When files are received, this layer tells the upper layers.

     Transport layer
     ---------------
     This layer handles routing and transport of NetMail, EchoMail and file
     attaches. The format of mailpackets is defined in this layer, except
     the internal structure of a packed message.

     A mail processor takes received NetMail and EchoMail and places it in
     the local message base. It also looks there for messages to send.

     Presentation layer
     ------------------
     Here are the internal structure of a packed message defined.

     In TYPE-2, this layer is totally mixed up with the Transport layer. In
     new packet formats, they will hopefully be separated.

     Application layer
     -----------------
     Here are the local message base (stored messages) defined.

     Interaction between layers
     ==========================

     Interaction between Session layer and Transport layer
     -----------------------------------------------------
     The Session and Transport layers does only interact between sessions,
     not during them. The reason is that is should be possible to keep them
     in different programs and implement it in single tasking operating
     systems like MS-DOS. This doesn't prevent the Session and Transport
     layers from running simultaneously in a multitasking system.

     FIDONEWS 14-23               Page 13                   9 Jun 1997


     Comments
     ========
     There is one problem with this model, how to describe the File Request
     server function. Sending File Requests are no problems, that's just a
     File Attach with a *.REQ file. The File Request server function have
     to be implemented directly in the Session layer.

     -----------------------------------------------------------------


       | Document: FSC-0081 Part A
       | Version:  001
       | Date:     01 Mar 1995
       |
       | Mikael Stoldal, 2:201/337

                              A TYPE-3 Packet proposal
                         Mikael Stoldal, 2:201/337@FidoNet

     Status of this document
     =======================
     Copyright (C) 1992-1994 by Mikael Stoldal.

     This document may be freely distributed and copied. The standard
     described may be implemented by anybody. You may not distribute
     modified versions of this document without written permission from the
     author.

     Fido and FidoNet are registered trademarks of Tom Jennings and Fido
     Software.

     Introduction
     ============
     This is a proposal on a new packet format for use in FidoNet and other
     FTNs (FTN = FidoNet Technology Network). This format can be used for
     both NetMail (private point-to-point mail) and EchoMail (electronic
     conferences).

     This document defines the transport layer. It also includes a
     presentation layer definition, but that can be changed without
     affecting the transport layer. It also includes a application layer
     (stored messages) definition,
     but it's not mandatory.

     This packet format conforms with FSC-39, rev 4. It has the PktType
     field in the header at the same position as TYPE-2 and it contains a
     capability word at the same position as TYPE-2+ (but no CW validation
     copy). The packet header has also the same size as in TYPE-2. This
     should make it easy to implement mail-processors supporting both TYPE-
     2 and TYPE-3.

     This packet format separates the header from the message data and the
     header is extensible. A mail processor (the transport layer) doesn't
     have to look at the message data.

     This format eliminates most kludges currently used in TYPE-2.
     FIDONEWS 14-23               Page 14                   9 Jun 1997


     This packet format allows multiple AreaTags in EchoMail.

     This packet format is much more extensible than TYPE-2 and is probably
     easier to implement.

     This packet format allows up to 4 GigaBytes large messages and allows
     binary data in messages, this makes it possible to implement
     multimedia capabilities in the future.

     Definitions
     ===========

     Characters
     ----------
     In this document, literal characters are written as two uppercase
     hexadecimal (base 16, 0..9A..F) digits following by lowercase h, e.g.
     "1Fh". The following abbreviations are used: "NUL" means 00h, "CR"
     means 0Dh and "space" means 20h (the quotation marks are not
     included).

     Basic data types
     ----------------
     Name      Length  Description
     ----------------------------------------------------------------------
     ShortInt    1     8-bit unsigned integer.
     Integer     2     16-bit unsigned integer, Intel 8086 byte order.
     LongInt     4     32-bit unsigned integer, Intel 8086 byte order.
     Byte        1     Field of 8 bits.
     Word        2     Field of 16 bits, Intel 8086 byte order.
     String[n]   n     Fixed length string of n bytes, NUL-padded.
     String{n} max n   Variable length string of max n bytes, NUL-
                       terminated.
                       n includes the terminating NUL.
     String            Variable length string, not terminated.

     Address
     -------
     Field      Type            Description
     Range
     ----------------------------------------------------------------------
     Zone       Integer         Zone address.
     1..65535
     Net        Integer         Net address.
     1..65535
     Node       Integer         Node address.
     0..65535
     Point      Integer         Point address or zero if boss.
     0..65535

     FTN address in text format
     --------------------------
     An FTN address in text format must, unless otherwise stated, be in the
     Zone:Net/Node[.Point] format, where .Point must be excluded if point
     is zero, included otherwise.

     TimeStamp
     FIDONEWS 14-23               Page 15                   9 Jun 1997


     ---------
     A LongInt which contains the number of seconds since 00:00:00 1st
     January 1970 UTC.

     Organization
     ------------
     An organization is a network such as FidoNet, VirNet, SigNet or
     InterNet.  It's sometimes called "domain", but I use the term
     organization to avoid confusion with InterNet domains.

     Reserved
     --------
     All fields marked "reserved for future extension" must be zeroed when
     creating/writing and ignored when reading. They might be defined by
     future revisions of this document.

     Filenames
     =========
     It's recommended to use the naming scheme in FTS-LIST, for both
     NetMail and EchoMail. There should be no problem with using the same
     name space for TYPE-2 and TYPE-3 packets because the packet headers
     are enough compatible.

     Packet format
     =============
     Packet header
     Zero or any number of data records.
     00h 00h

     The first two bytes of a data record is used to check for the end of a
     packet. If both are zero, the end is reached (and the rest, if any,
     should be ignored).

     Packet header
     =============
     Field      Type            Description
     ----------------------------------------------------------------------
     PktOrig    Address         The node who created this packet.
     PktDest    Address         The node who should receive this packet.
     SubType    Integer         Packet contents (see below).
     PktType    Integer         Always 3.
     PktDate    TimeStamp       When the packet was created.
     ProdCode   Integer         FTSC Product Code.
                                Programs without Product Code must use
                                65535.
     MajorVer   ShortInt        Major product version.
     MinorVer   ShortInt        Minor product version.
     Org        String[16]      Organization (see below).
     CapWord    Word            Capability Word (see FSC-39).
     Password   String[8]       Packet password.
     ExtraInfo  String[4]       Reserved for future extension.

     SubType
     -------
     Defines what the packet contains.

     FIDONEWS 14-23               Page 16                   9 Jun 1997


     If this field is zero, data record is defined by the "Packed message"
     part of this document. If this field is non-zero, data record is not
     defined by this document.

     This field can be used for two things. The first is to define new
     packet types without having to use a new packet header. The second is
     to allow distribution of other things than Email.

     Organization
     ------------
     This field contains the name of the organization the packet travels
     in. This field applies to both PktOrig and PktDest since packets are
     intra-organization.

     Packed message
     ==============
     The messages should be in chronological order in a packet.

     Field      Type              Description
     ----------------------------------------------------------------------
     HeadSize   Integer           Size of the message header (see below).
     MsgFlags   Word              Message flags (see below).
     MsgDate    TimeStamp         When the message was created.
     MsgID      LongInt           Unique message identifier (see below).
     ReplyID    LongInt           Reply linkage information (see below).
     MsgLength  LongInt           Size of MsgData.
     MsgOrig    Address           The node who created this message.
     MsgDest    Address           The node who should receive this message.
     CharSet    ShortInt          Character set (see below).
     MsgType    ShortInt          Type of MsgData (see below).
     Area       String{255}       AreaTag(s) (see below).
     OrigAddr   String{255}       Origin address in text format (see
                                  below).
     ReplyAddr  String{255}       Reply linkage information (see below).
     FromUser   String{255}       Who wrote this message?
     ToUser     String{255}       To whom?
     Subject    String{255}       Subject or one filename
                                  (for file attaches and requests).
     Path       String{65535}     Path (see below).
     HeadExt    String            Header extension fields (see below).
     MsgData    String            Message data (see below).

     HeadSize
     --------
     The total size of the message header (all fields except MsgData).
     Since this is an Integer, the header can't be bigger than 65535 bytes
     and Path can never reach it's maximum length (how big it can be
     depends on how big the rest of the header is).

     Message flags
     -------------
     Bit  Flag          Meaning
     ----------------------------------------------------------------------
      0   Pvt           Private message.
      1   File          File attach message.
      2   FileReq       File request message.
     FIDONEWS 14-23               Page 17                   9 Jun 1997


      3   UpdReq        File update request message.
      4   Direct        Do not route this message.
      5   Crash         High priority mail.
      6   Hold          Hold for pickup.
      7   IMM           Immediate mail (highest priority).
      8   RRQ           Return receipt request (see below).
      9   CRQ           Confirm receipt request (see below).
     10   IRR           Is return receipt (see below).
     11   Machine       Message to a program (see below).
     12   NoForCC       CC in NetMail, NoForward in EchoMail (see below).
     13   Permanent     Message must not be purged by age (see below).
     14   Foreign       Message is from another organization.
     15   reserved      Reserved for future extension.

     RRQ, CRQ and IRR
     ----------------
     The RRQ and CRQ flags without IRR is used to ask the software at the
     final destination to generate a receipt message to the sender. The
     receipt to an RRQ flagged message must be generated when the message
     is received, and this receipt must have the IRR and RRQ flags set. The
     receipt to a CRQ flagged message must be generated when it has been
     read by its addressee, and this receipt must have the IRR and CRQ
     flags set.

     A receipt must have the ReplyAddr and ReplyID fields set as if it was
     a reply to the original message.

     It's up to each network's policy to decide if all systems must support
     this, no system are allowed to support this or all systems are allowed
     but not forced to support this.

     Machine
     -------
     The Machine flag indicates that this message is addressed to a program
     and not a human. A mail processor should store such messages as
     defined in the "Stored message" section later in this document so the
     program doesn't have to support 4711 different message base formats.
     The name of the program must be in the ToUser field.

     Carbon Copy
     -----------
     The CC flag is used for sending a NetMail message to several nodes.
     Which nodes is determined by the MsgDest field.

     If the message is addressed to a Zone Coordinator, the message is
     destined for all nodes in that zone. If the message is addressed to a
     Region Coordinator, the message is destined for all nodes in that
     region. If the message is addressed to a Net Coordinator, the message
     is destined for all nodes in that net. If the message is addressed to
     a HUB, the message is destined for all nodes under that HUB.

     If the receiver of a CC message have other coordinators (or HUBs)
     below, it must send the message to them as CC's too.

     If the ToUser field is empty the message is considered to be addressed
     to the SysOp and the name is taken from the nodelist (or set to
     FIDONEWS 14-23               Page 18                   9 Jun 1997


     "SysOp").  This must be done by the system immediate before the
     destination (usually the destination's HUB).

     Permanent
     ---------
     This flag indicates that the message must not be removed when old
     messages is cleaned out.

     A new message with this flag automatically erase an old message with
     the same data in the Subject field. If you want to erase a permanent
     message without replacing it with a new, then post an empty message
     with the Permanent flag and the appropriate data in the Subject field.

     This flag can only be used in EchoMail.

     OrigAddr
     --------
     This field must contain the true origin address of the message in text
     format followed by an "@" (40h) and the name of the originating
     organization.

     Message ID
     ----------
     The origin address and MsgID fields are used as a unique message
     identifier.  How the MsgID field is generated is left to the
     implementor, but it must be unique for each message generated on a
     given node in at least three years.  MsgID must normally not be zero,
     zero is used to indicate lack of Message-ID.  With this system these
     two fields together is unique for every message, and can be used for
     duplicate detection and other things.

     Reply linkage information
     -------------------------
     In a reply the ReplyAddr and ReplyID fields must be identical to the
     origin address, and MsgID fields in the replied message. A message
     which is not a reply must have these fields empty. Use the ReplyAddr
     field to check this.

     Area
     ----
     A list of one or more AreaTags in EchoMail, just a NUL in NetMail. If
     the list contains more than one tag, they are separated by space. 00h
     through 1Fh are not allowed in this field (except NUL as the
     terminator).

     Path
     ----
     This field contains a series of addresses separated by space. The
     first system must place its address in this field and every system
     that routes the message must add its address to this field,

     Note that the first address in this field and the address in the
     MsgOrig field doesn't have to be the same.

     The first address must be the origin address in this format:
     zone:net/node.point@organization
     FIDONEWS 14-23               Page 19                   9 Jun 1997


     In the other addresses organization, zone, net and node must be
     omitted if same as the previous address.

     The other addresses must be in one of these formats:
     zone:net/node.point@organization
     zone:net/node.point
     net/node.point
     node.point
     .point

     .point must be excluded if point is zero, except when .0 stands alone.

     Example:
     1:123/324@FidoNet sends a routed NetMail message to 2:224/546.5;
     1:123/300, 1:123/0, 1:12/0, 1:1/2, 2:22/888, 2:22/0, 2:224/0,
     2:224/546 and 2:224/546.3 routes the message (in that order). The path
     field must in this case be "1:123/324@FidoNet 300 0 12/0 1/2 2:22/888
     0 224/0 546 .3" when
     2:224/546.5 receives the message. Note that the message is routed via
     a point, that might not be so common but it's technically possible.

     In EchoMail, the Path field can also contain addresses suffixed by an
     exclamation mark ("!", 21h). This means that that node hasn't routed
     the message, but the message has been sent to him. Similar to SEEN-
     BY's in FTS-4. However, this should only be used when necessary.

     Never send an EchoMail message to a node listed in the Path field;
     regardless if the address is suffixed by an exclamation mark or not.

     If the message originates in a non-FTN organization, the name of the
     origin organization prefixed by an "@" (40h) must be placed before the
     address of the gateway. In such cases there may also be some other FTN
     addresses before the non-FTN organization name if the message have
     travelled from an FTN, via a non-FTN and to a FTN again.

     Example:
     [e-mail] in InterNet sends a routed NetMail message to
     1:222/345 in FidoNet via the gateway 1:222/111 and 1:222/300. The path
     field must in this case be "@InterNet 1:222/111@FidoNet 300" when
     2:222/345 receives the message.

     If there's not enough room to update the Path field (add what you
     should and have at least two bytes left), put a single "$" (24h) in it
     instead (and a space between it and the last address).

     This field has the same format as the PTH line specified in FSC-44
     (except the "$"). Read FSC-44 for more information.

     HeadExt
     -------
     This field contains zero or more NUL-terminated strings. The end of
     this field can be determined by the HeadSize field, but there must be
     a NUL after the last string anyway. If there are no strings here,
     there must not be any NUL either.

     Each string here is a header extension field. A header extension field
     FIDONEWS 14-23               Page 20                   9 Jun 1997


     contains a keyword followed by a space and some data. A header
     extension field can contain only a keyword with no data, in such case
     a space must not be used either.

     Inter-organization messages
     ---------------------------
     To send a message to an other organization place the final address in
     text format followed by an "@" (40h) and the name of the destination
     organization in a header extension field with the keyword "DEST" and
     address the message to a gateway.

     If the message must travel over more than one organization-border, the
     addresses to each gateway can be pointed out by header extension
     fields with the keyword "ROUTE". ROUTE fields contains addresses in
     the same format as DEST lines. The order of the ROUTE fields is
     important and the DEST field must be after the ROUTE field(s). When
     the gateway pointed by a ROUTE field processes the message it must
     change "ROUTE" to "ROUTD".

     Note: The gateway from your organization are pointed out by the
     MsgDest field so there must not be a ROUTE field for that gateway.

     Example:
     You are 34:65/12@StrangeNet and want to send a message to
     [e-mail] in InterNet. StrangeNet hasn't got any gateway
     to InterNet, but FidoNet has gateways to both StrangeNet and InterNet.
     In that case the message may have the following header extension
     fields:
     ROUTE 1:1/20@FidoNet
     DEST [e-mail]@InterNet

     Messages from other organizations (NetMail or EchoMail doesn't matter)
     must have their origin addresses (including @organization as mentioned
     before) stored in the OrigAddr field and the Foreign flag set.  The
     MsgOrig field in the header must contain the address of a
     bidirectional gateway.

     The MsgID field must be generated using the message-ID in the
     originating organization, if that is possible.  If the originating
     network doesn't have any message-ID that can be used to create the
     MsgID field, the MsgID field must be set to zero. If two identical
     messages (with identical message-ID) enters an FTN organization at two
     different gateways, they should get the same MsgID. The same counts
     for ReplyID. ReplyAddr must also be transferred if present in the
     original message.

     If the other organization uses a message-ID format that can't be
     transparently mapped to MsgID, a ORIGID header extension field is
     created with a direct copy of the original message-ID (both address
     and serial number). The same is done with reply-linkage information in
     a ORIGREF header extension field. This information is used if the
     message should be gated back to the original network.
     Example with message from InterNet:
     ORIGID <[e-mail]>
     ORIGREF <[e-mail]>

     FIDONEWS 14-23               Page 21                   9 Jun 1997


     Message routing
     ---------------
     The transport layer (including intermediate systems (systems handling
     in-transit messages)) are not allowed to change anything in the
     MsgDate, MsgID, ReplyID, MsgLength, CharSet, MsgType, OrigAddr,
     ReplyAddr, FromUser, ToUser, Subject and MsgData fields. No flags may
     be changed by the transport layer except the Foreign flag at gateways.
     The only exception is if the message have to be converted to another
     packet type.

     An intermediate system must update the Path field, both in NetMail and
     EchoMail.

     In EchoMail, the Area field may be changed.

     An intermediate system are allowed to add or change header extension
     fields.

     An intermediate system can add a header extension field with the
     keyword "Via". The Via field contains information about the system and
     when it processed the message. It's up to each network's policy to
     decide if this is allowed in NetMail, EchoMail or both.

     If the header is changed, the HeadSize field must be updated.

     EchoMail
     --------
     This section lists the changes to FTS-4 needed to implement EchoMail
     with this packet format.

     SEEN-BY lines are not to be used. The Path field is used instead of
     PATH lines. The Area field is used instead of the AREA line. The
     MsgOrig and OrigAddr fields must contain the origin addresses of the
     message. A unaddressed EchoMail message must have the ToUser field
     empty, unless there is a good reason to put something there.

     The MsgDest field must be used as in NetMail. If you receive a
     EchoMail message not addressed to any of you addresses, you must
     handle it as in-transit NetMail. This makes it possible to route
     EchoMail through nodes not connected to the area. This can be
     performed inter-organization as well.

     Since the lack of complete SEEN-BY's, an EchoMail processor must use
     the single-pass technique. That means that it must export a message to
     all its downlinks at the same time as it tosses the message, before it
     goes into the local message base (it doesn't even have to get there if
     the area is pass-through). With this technique the tosser can do what
     ever it wants with the message before it stores it in the local
     message base since the message will never get out of it again (except
     when a rescan function is invoked, but the requesting system will have
     to stand that).

     A system which receives an EchoMail message with the NoForward flag
     set must not export that message. This flag is indented for EchoMail
     processors with a rescan function, all rescanned messages must have
     the NoForward flag set.
     FIDONEWS 14-23               Page 22                   9 Jun 1997


     The tear and origin lines have no technical meaning (the origin
     address is stored elsewhere) so no program is forced to create them.
     Additionally, a program must not require them.

     To distinguish EchoMail from NetMail, check the Area field. NetMail
     messages have empty Area fields.

     Cross-posting a message in several areas is preformed by storing
     multiple AreaTags in the Area field. If some of your downlinks don't
     have all the areas listed in the Area field then you must remove the
     AreaTags for the areas they don't have. All copies must still have the
     same MsgID. If you receive several messages with the same MsgID but
     different Area then you must join them into a single message and put
     all different AreaTags in the Area field (but not the same twice).
     Compare all fields in the header up to and including Subject (except
     Area) and not only MsgID.

     When preforming dupchecking with MsgID, compare all fields in the
     header up to and including Subject and not only MsgID.

     CharSet
     -------

     Value    Character set
     ----------------------------------------------------------------------
     1..99    ISO 8859 (8 bit)
     100      ISO 10646 16 bit (Unicode)
     101..149 Reserved for other 16 bit character sets
     150      ISO 10646 32 bit
     151      PC8-437 (The Original)
     152      PC8-850 (Multilingual)
     153      PC8-852 (Slavic)
     154      PC8-860 (Portuguese)
     155      PC8-863 (Canadian-French)
     156      PC8-865 (Nordic)
     157..199 Reserved for other 8 bit character sets
     200..255 reserved

     PC8 means IBM's codepage (8 bit).

     CharSet=1 means ISO 8859-1 (Latin-1), CharSet=2 means ISO 8859-2 and
     so on.

     CharSet concerns FromUser, ToUser and Subject. It may also concern
     MsgData.

     Combined characters are built by 02h followed by a modifier and the
     base character. If you can't display the combined character, just
     ignore the modifier and display the base character unmodified. A
     combined character contains three bytes and are counted as three
     bytes. See FSC-51 for more information on this. There are a few things
     in FSC-51 that doesn't apply to this format: this method is allowed on
     all 8 bit character sets, not only Latin-1, and the byte values 80h
     through 9Fh are allowed. This can only be used for 8 bit character
     sets. Combined character can be used in FromUser, ToUser and Subject,
     it may also be allowed in MsgData.
     FIDONEWS 14-23               Page 23                   9 Jun 1997


     MsgLength, MsgType and MsgData
     ------------------------------
     If the MsgData field contains nothing (MsgLength is zero), it's an
     empty message. An empty message must be forwarded and routed as any
     other message.  An empty message must not be stored in the local
     message base (but read about the Permanent flag).

     If MsgType is zero, MsgData is defined by the "Message text" part of
     this document.

     If MsgType is non-zero, the MsgData field is not defined by this
     document.

     Message text
     ============
     This part defines the presentation layer.

     The CharSet field in the header concerns the message text except
     binary extension fields. Combined characters can be used in the
     message text except in binary extension fields.

     If a 16 or 32 bit character set is used all characters are two or four
     bytes so all control codes must be prefixed by 00h or 00h 00h 00h. The
     bytes alone can be in printable character. The length of binary
     extension fields is still counted in bytes.

     All 256 byte values (including NUL) are accepted in the message text.
     00h through 1Fh are control codes and must not be used to represent
     printable characters.

     A paragraph (also called "physical line") is ended with CR.

     8Dh (sometimes called "Soft CR") must not be used as a line separator
     since it represents a printable character in some character sets.

     01h first at a physical line (i.e. the first character of the message
     text or the character immediately after a CR) means that this line is
     a extension line. See below for more information.

     00h first at a physical line (except in another binary extension
     field) indicates the start of an long binary extension field. 00h is
     followed by a LongInt and up to almost 4 GigaBytes of binary data. A
     binary extension field is not terminated in any way, it's length is
     stored in the LongInt (the 00h and the LongInt itself is not included
     in the length).

     15h first at a physical line (except in another binary extension
     field) indicates the start of an short binary extension field. 15h is
     followed by a ShortInt and up to 255 bytes of binary data. A binary
     extension field is not terminated in any way, it's length is stored in
     the ShortInt (the 15h and the Integer itself is not included in the
     length).

     Attributes:
     03h = Turn off all attributes
     04h = Bold
     FIDONEWS 14-23               Page 24                   9 Jun 1997


     05h = Italic
     06h = Underline
     17h = All caps (lower case letters as small caps)
     19h = Subscript
     1Ah = Superscript
     1Ch = Blinking
     1Dh = Inverted
     1Eh = Concealed
     Subscript automatically turns off superscript and vice versa. All
     other attributes can be used together. If an attribute already is on,
     it's turned off by the same code again. If your system doesn't support
     an attribute, just ignore it. CR turns off all attributes.

     To quote a message begin a physical line with 1Fh followed by the
     initials of the person you are quoting and another 1Fh. Use just two
     1Fh if you don't want any initials. Successive quoting is marked with
     more 1Fh:s immediate after the two first ones. A quote is ended with
     CR. It's up to each implementor to decide how to display quoted text,
     but it must be possible to distinguish it from normal text. It's
     recommended to display it in another color if possible. You must
     translate the quote to the same character set used in the rest of the
     message.

     The last paragraph of the message text must be terminated by a CR
     (i.e. the last character of the message text must be a CR unless a
     binary extension field is last).

     Extension lines
     ---------------
     An extension line contains a keyword followed by a space and some
     data. A extension line can contain only a keyword with no data, in
     such case a space must not be used either. An extension line is ended
     like a paragraph.

     Extension lines may not contain 00h through 1Fh. If you want binary
     data, use a binary extension field instead.

     Extension lines are control information any should not be displayed to
     the user. If you want "hidden lines", then use the Concealed attribute
     rather than an extension line.

     Information that is relevant for the transport layer must be placed in
     a header extension field rather than in an extension line.

     Extension lines can be useful for describing a binary extension field.

     Currently defined extension lines
     ---------------------------------
     A extension line with the keyword FILE is used for sending files
     embedded in the message text. The keyword is followed by a eight digit
     uppercase hexadecimal number containing a TimeStamp for the file, a
     space and the filename. The filename can contain all chars valid for
     extension lines (including space) and must be at least 1 char and at
     most 255 chars. The file is stored in a binary extension field
     immediate after the FILE line.  Examples:
     FILE AB34F657 FILE.EXT
     FIDONEWS 14-23               Page 25                   9 Jun 1997


     FILE 1234ABCD This is a filename

     Stored message
     ==============
     This is a description of the application layer, the local message
     base.

     It is recommended to use this format to store NetMail messages
     locally. It can also be used for EchoMail, but that's not necessary.

     Each message is stored as a single file which must have a hexadecimal
     number from 00000001 to FFFFFFFF as the base name and the extension
     MS3 (to distinguish from TYPE-2 stored messages).

     Messages can be stored in two ways. Either the same way as TYPE-2 with
     one directory for each area (including NetMail), in that case the Area
     field must be empty in all messages. Or all messages in the same
     directory with the area field used to indicate what/which area the
     message belongs to (or empty to indicate NetMail). The second format
     is useful if you normally store EchoMail in an other format and only
     use this format for messages with the Machine flag.

     Field      Type              Description
     ----------------------------------------------------------------------
     SRdate     TimeStamp         When the message was sent or received
                                  (see below).
     ReplyTo    LongInt           Message which this replies (see below).
     Reply1st   LongInt           First reply to this message (see below).
     ReplyNext  LongInt           Next reply to this message (see below).
     LocalFlags Word              Local flags (see below).
     Cost       Integer           Cost of sending in the lowest currency
     unit.
     HeadSize   Integer           Size of the message header (see below).
     MsgFlags   Word              Same as packed message.
     MsgDate    TimeStamp         Same as packed message.
     MsgID      LongInt           Same as packed message.
     ReplyID    LongInt           Same as packed message.
     MsgLength  LongInt           Same as packed message.
     MsgOrig    Address           Same as packed message.
     MsgDest    Address           Same as packed message.
     CharSet    ShortInt          Same as packed message.
     MsgType    ShortInt          Same as packed message.
     Area       String{255}       AreaTag(s) (see above).
     OrigAddr   String{255}       Same as packed message.
     ReplyAddr  String{255}       Same as packed message.
     FromUser   String{255}       Same as packed message.
     ToUser     String{255}       Same as packed message.
     Subject    String{255}       Same as packed message.
     Path       String{65535}     Path (see below).
     HeadExt    String            Same as packed message.
     MsgData    String            Same as packed message.

     HeadSize
     --------
     The total size of the message header (all fields except MsgData).
     Since this is an Integer, the header can't be bigger than 65535 bytes
     FIDONEWS 14-23               Page 26                   9 Jun 1997


     and Path can never reach it's maximum length (how big it can be
     depends on how big the rest of the header is).

     Please note that this won't contain the same value when the same
     message is placed in a packet because SRdate, LocalFlags, ReplyTo,
     Areply and Cost isn't included then and Area might not have the same
     length.

     Local flags
     -----------
     Bit  Flag          Meaning
     ----------------------------------------------------------------------
     0    Local         Message is created locally.
     1    InTransit     Message is not destined for this system.
     2    Orphan        Unknown destination.
     3    KillSent      Remove message after it has been sent.
     4    DelSent       Delete attached file(s) after they have been sent.
     5    TruncSent     Truncate attached file(s) after they have been
                        sent.
     6    Sent          Message has been sent.
     7    Read          Message has been read by the SysOp.
     8    Rcvd          Message has been read by its addressee.
     9    Lock          Lock the message for further access.
     10   DontSend      Do not send the actual message but send attached
                        files, make file requests and poll the destination
                        if necessary.
     11   unused        Reserved for future extension.
     12   unused        Reserved for future extension.
     13   unused        Reserved for future extension.
     14   unused        Reserved for future extension.
     15   unused        Reserved for future extension.

     Note that "sent" also can mean "picked up".

     SRdate
     ------
     The meaning of this field is determined by the Local and Sent flags.
     Local but not Sent: Meaningless, must be zero.
     Local and Sent: When the message was sent or picked up.
     Not Local: When the message arrived to this system.

     Reply linking
     -------------
     The ReplyTo field points at the message which the current message
     replies.  The Reply1st field points at the first reply to the current
     message (the reply with lowest number); a messages with no replies
     must have this field set to zero. The ReplyNext field points at the
     next reply the same message as the current message; this field must be
     zero if there are no more replies to the message the current message.
     A message which is no reply must have the ReplyTo and ReplyNext fields
     set to zero.

     With this system there is possible to keep track of an unlimited
     number of replies to any message.

     Path
     FIDONEWS 14-23               Page 27                   9 Jun 1997


     ----
     If the local flag is set, this field must be empty. It's the mail
     processors responsibility to insert the address here when placing the
     message in a packet.

     When the mail processor tosses an incoming message, it must copy the
     Path field from the packet.

     Control file
     ------------
     In each message directory (both EchoMail and NetMail) there must be a
     file named LASTREAD. When an area is renumbered, this file must be
     updated.

     Field      Type            Description
     ----------------------------------------------------------------------
     LastRead   LongInt         The last message read.
     HighRead   LongInt         The highest message read.
     HighWater  LongInt         High-water mark (only used with EchoMail).
                                This field is used by the EchoMail
                                processor to store the number of the last
                                scanned message.

     Notes
     =====
     If you are implementing this and something confuses you, ask someone
     who knows. Please don't guess how it should be.

     Credits
     =======
     Thanks to Krister Hansson-Renuad, Johan Olofsson, Nils Hammar, Jonas
     Hogstrom, Mats Gefvert and others who have helped me developing this.

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 28                   9 Jun 1997


     =================================================================
                            COORDINATORS CORNER
     =================================================================


     Nodelist-statistics as seen from Zone-2 for day 157
     By Ward Dossche, 2:292/854
        ZC/2

      +----+------+------------+------------+------------+------------+--+
      |Zone|Nl-129|Nodelist-136|Nodelist-143|Nodelist-150|Nodelist-157|%%|
      +----+------+------------+------------+------------+------------+--+
      |  1 |  8430| 8367   -63 | 8277   -90 | 8277     0 | 8182   -95 |31|
      |  2 | 15904|15879   -25 |15855   -24 |15835   -20 |15774   -61 |60|
      |  3 |   800|  800     0 |  761   -39 |  765     4 |  758    -7 | 3|
      |  4 |   543|  543     0 |  543     0 |  543     0 |  519   -24 | 2|
      |  5 |    87|   87     0 |   87     0 |   87     0 |   87     0 | 0|
      |  6 |  1083| 1083     0 | 1077    -6 | 1078     1 | 1078     0 | 4|
      +----+------+------------+------------+------------+------------+--+
           | 26847|26759   -88 |26600  -159 |26585   -15 |26398  -187 |
           +------+------------+------------+------------+------------+

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 29                   9 Jun 1997


     =================================================================
                                 NET HUMOR
     =================================================================


     Date: Sun, 25 May 1997 22:08:50 -0700
     From: Shari <[e-mail]>
     Organization: OREGON - USA
     To: [e-mail]
     CC: [e-mail]
     Subject: NEVERMORE
     Sender: [e-mail]
     Reply-To: [e-mail]

     Once upon a midnight dreary, fingers cramped and vision bleary,
                System manuals piled high and wasted paper on the floor,
                       Longing for the warmth of bedsheets,
                       Still I sat there, doing spreadsheets:
                         Having reached the bottom line,
                         I took a floppy from the drawer.
              Typing with a steady hand, I then invoked the SAVE command
              But got instead a reprimand: it read "Abort, Retry, Ignore."

                Was this some occult illusion? Some maniacal intrusion?
              These were choices Solomon himself had never faced before.
                         Carefully, I weighed my options.
                      These three seemed to be the top ones.
                         Clearly, I must now adopt one:
                          Choose Abort, Retry, Ignore.

                       With my fingers pale and trembling,
                       Slowly toward the keyboard bending,
                Longing for a happy ending, hoping all would be restored,
                          Praying for some guarantee
                           Finally I pressed a key --
                        But on the screen what did I see?
                          Again: "Abort, Retry, Ignore."

                       I tried to catch the chips off-guard --
                        I pressed again, but twice as hard.
                         Luck was just not in the cards.
                          I saw what I had seen before.
                          Now I typed in desperation
                          Trying random combinations
                         Still there came the incantation:
                         Choose: Abort, Retry, Ignore.

              There I sat, distraught, exhausted, by my own machine
                accosted Getting up I turned away and paced across the
                office floor.  And then I saw an awful sight:
                        A bold and blinding flash of light --
           A lightning bolt had cut the night and shook me to my very core.
                        I saw the screen collapse and die
                         "Oh no -- my database", I cried
                         I thought I heard a voice reply,
                        "You'll see your data Nevermore."
     FIDONEWS 14-23               Page 30                   9 Jun 1997


                           To this day I do not know
                        The place to which lost data goes
                 I bet it goes to heaven where the angels have it stored.
                          But as for productivity, well
                         I fear that it goes straight to hell
                         And that's the tale I have to tell
                        Your choice: Abort, Retry, Ignore.

      -30-

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 31                   9 Jun 1997


     =================================================================
                                  NOTICES
     =================================================================

                                Future History

     12 Jun 1997
        Independence Day, Russia.

      1 Jul 1997
        Canada Day - Happy Birthday Canada.

      9 Jul 1997
        Independence Day, Argentina.

      1 Aug 1997
        International FidoNet PENPAL [Echo] meeting in Dijon, France

     13 Oct 1997
        Thanksgiving Day, Canada.

      1 Dec 1997
        World AIDS Day.

     10 Dec 1997
        Nobel Day, Sweden.

     12 Jan 1998
        HAL 9000 is one year old today.

     22 May 1998
        Expo '98 World Exposition in Lisbon (Portugal) opens.

      1 Dec 1998
        Fifteenth Anniversary of release of Fido version 1 by
        Tom Jennings.

     31 Dec 1999
        Hogmanay, Scotland. The New Year that can't be missed.

      1 Jan 2000
        The 20th Century, C.E., is still taking place thru 31 Dec.

     15 Sep 2000
        Sydney (Australia) Summer Olympiad opens.

      1 Jan 2001
        This is the actual start of the new millennium, C.E.

     -- If YOU have something which you would like to see in this
        Future History, please send a note to the FidoNews Editor.

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 32                   9 Jun 1997


     =================================================================
                         FIDONET SOFTWARE LISTING
     =================================================================


     [The SOF Keeper is out of town this week. Here's last week's
      edition.] Ed.

     Latest Greatest Software Versions
     by Peter E. Popovich, 1:363/264

     A fairly quiet week around here. Things seems to be settling down into
     some sense of order...

     -=- Snip -=-

     Submission form for the Latest Greatest Software Versions column

     OS Platform                             :
     Software package name                   :
     Version                                 :
     Function(s) - BBS, Mailer, Tosser, etc. :
     Freeware / Shareware / Commercial?      :
     Author / Support staff contact name     :
     Author / Support staff contact node     :
     Magic name (at the above-listed node)   :

     Please include a sentence describing what the package does.

     Please send updates and suggestions to: Peter Popovich, 1:363/264

     -=- Snip -=-

     MS-DOS:
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     Act-Up         4.6      G D Chris Gunn        1:15/55     ACT-UP
     ALLFIX         4.40     T S Harald Harms      2:281/415   ALLFIX
     Announcer      1.11     O S Peter Karlsson    2:206/221   ANNOUNCE
     BGFAX          1.60     O S B.J. Guillot      1:106/400   BGFAX
     Binkley Docs   2.60     M F Bob Juge          1:1/102     BDOC_260.ZIP
     BinkleyTerm    2.60     M F Bob Juge          1:1/102     BDOS_260.ZIP
     BinkleyTerm-XE XR4      M F Thomas Waldmann   2:2474/400  BTXE_DOS
     CFRoute        0.92     O G C. Fernandez Sanz 2:341/70    CFR
     CheckPnt       1.0a     O G Michiel vd Vlist  2:500/9     CHECKPNT
     FastEcho       1.45a    T S Tobias Burchhardt 2:2448/400  FASTECHO
     FastEcho/16    1.45a    T S Tobias Burchhardt 2:2448/400  FE16
     FidoBBS (tm)   12u      B S Ray Brown         1:1/117     FILES
     FrontDoor      2.12     M S JoHo              2:201/330   FD
     FrontDoor      2.20c    M C JoHo              2:201/330   FDINFO
     GEcho          1.00     T S Bob Seaborn       1:140/12    GECHO
     GEcho/Plus     1.11     T C Bob Seaborn       1:140/12    GECHO
     GEcho/Pro      1.20     T C Bob Seaborn       1:140/12    GECHO
     GIGO           07-14-96 G S Jason Fesler      1:1/141     INFO
     GoldED         2.50     O S Len Morgan        1:203/730   GED
     GoldED/386     2.50     O S Len Morgan        1:203/730   GEX
     FIDONEWS 14-23               Page 33                   9 Jun 1997


     GoldED Docs    2.50     O S Len Morgan        1:203/730   GEM
     GoldNODE       2.50     O S Len Morgan        1:203/730   GEN
     Imail          1.75     T S Michael McCabe    1:1/121     IMAIL
     ImCrypt        1.04     O G Michiel vd Vlist  2:500/9     IMCRYPT
     InfoMail/86    1.21     O F Damian Walker     2:2502/666  INFOMAIL
     InfoMail/386   1.21     O F Damian Walker     2:2502/666  INFO386
     InterEcho      1.19     T C Peter Stewart     1:369/35    IEDEMO
     InterMail      2.29k    M C Peter Stewart     1:369/35    IMDEMO
     InterPCB       1.52     O S Peter Stewart     1:369/35    INTERPCB
     IPNet          1.11     O S Michele Stewart   1:369/21    IPNET
     JD's CBV       1.4      O S John Dailey       1:363/277   CBV
     Jelly-Bean     1.01     T S Rowan Crowe       3:635/727   JELLY
     Jelly-Bean/386 1.01     T S Rowan Crowe       3:635/727   JELLY386
     JMail-Hudson   2.81     T S Jason Steck       1:285/424   JMAIL-H
     JMail-Goldbase 2.81     T S Jason Steck       1:285/424   JMAIL-G
     MakePl         1.9      N G Michiel vd Vlist  2:500/9     MAKEPL
     Marena         1.1 beta O G Michiel vd Vlist  2:500/9     MARENA
     Maximus        3.01     B P Tech              1:249/106   MAX
     McMail         1.0      M S Michael McCabe    1:1/148     MCMAIL
     MDNDP          1.18     N S Bill Doyle        1:388/7     MDNDP
     Msged          4.10     O G Andrew Clarke     3:635/728   MSGED41D.ZIP
     Msged/386      4.10     O G Andrew Clarke     3:635/728   MSGED41X.ZIP
     Opus CBCS      1.79     B P Christopher Baker 1:374/14    OPUS
     O/T-Track      2.66     O S Peter Hampf       2:241/1090  OT
     PcMerge        2.8      N G Michiel vd Vlist  2:500/9     PCMERGE
     PlatinumXpress 1.3      M C Gary Petersen     1:290/111   PX13TD.ZIP
     QuickBBS       2.81     B S Ben Schollnick    1:2613/477  QUICKBBS
     RAR            2.00     C S Ron Dwight        2:220/22    RAR
     RemoteAccess   2.50     B S Mark Lewis        1:3634/12   RA
     Silver Xpress
       Door         5.4      O S Gary Petersen     1:290/111   FILES
       Reader       4.4      O S Gary Petersen     1:290/111   SXR44.ZIP
     Spitfire       3.51     B S Mike Weaver       1:3670/3    SPITFIRE
     Squish         1.11     T P Tech              1:249/106   SQUISH
     StealTag UK    1.c...   O F Fred Schenk       2:284/412   STEAL_UK
     StealTag NL    1.c...   O F Fred Schenk       2:284/412   STEAL_NL
     T-Mail         2.599I   M S Ron Dwight        2:220/22    TMAIL
     Telegard       3.02     B F Tim Strike        1:259/423   TELEGARD
     Terminate      4.00     O S Bo Bendtsen       2:254/261   TERMINATE
     Tobruk         0.33     T G Paul Edwards      3:711/934   TOBRUK
     TosScan        1.01     T C JoHo              2:201/330   TSINFO
     TransNet       1.00     G S Marc S. Ressl     4:904/72    TN100ALL.ZIP
     TriBBS         11.0     B S Gary Price        1:3607/26   TRIBBS
     TriDog         11.0     T F Gary Price        1:3607/26   TRIDOG
     TriToss        11.0     T S Gary Price        1:3607/26   TRITOSS
     WaterGate      0.92     G S Robert Szarka     1:320/42    WTRGATE
     WWIV           4.24a    B S Craig Dooley      1:376/126   WWIV
     WWIVTOSS       1.36     T S Craig Dooley      1:376/126   WWIVTOSS
     xMail          2.00     T S Thorsten Franke   2:2448/53   XMAIL
     XRobot         3.01     O S JoHo              2:201/330   XRDOS

     OS/2:
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     ALLFIX/2       1.10     T S Harald Harms      2:281/415   AFIXOS2
     BGFAX          1.60     O S B.J. Guillot      1:106/400   BGFAX
     FIDONEWS 14-23               Page 34                   9 Jun 1997


     Binkley Docs   2.60     M F Bob Juge          1:1/102     BDOC_260.ZIP
     BinkleyTerm    2.60     M F Bob Juge          1:1/102     BOS2_260.ZIP
     BinkleyTerm-XE XR4      M F Thomas Waldmann   2:2474/400  BTXE_OS2
     CFRoute        0.92     O G C. Fernandez Sanz 2:341/70    CFR
     FastEcho       1.45a    T S Tobias Burchhardt 2:2448/400  FE2
     FleetStreet    1.19     O S Michael Hohner    2:2490/2520 FLEET
     GEcho/Pro      1.20     T C Bob Seaborn       1:140/12    GECHO
     GIGO           07-14-96 G S Jason Fesler      1:1/141     INFO
     GoldED         2.50     O S Len Morgan        1:203/730   GEO
     GoldED Docs    2.50     O S Len Morgan        1:203/730   GEM
     GoldNODE       2.50     O S Len Morgan        1:203/730   GEN
     ImCrypt        1.04     O G Michiel vd Vlist  2:500/9     IMCRYPT
     Maximus        3.01     B P Tech              1:249/106   MAXP
     Msged/2        4.10     O G Andrew Clarke     3:635/728   MSGED41O.ZIP
     PcMerge        2.3      N G Michiel vd Vlist  2:500/9     PCMERGE
     RAR            2.00     C S Ron Dwight        2:220/22    RAR2
     Squish         1.11     T P Tech              1:249/106   SQUISHP
     T-Mail         2.599I   M S Ron Dwight        2:220/22    TMAIL2
     Tobruk         0.33     T G Paul Edwards      3:711/934   TOBRUK
     XRobot         3.01     O S JoHo              2:201/330   XROS2

     Windows (16-bit apps):
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     BeeMail        1.0      M C Andrius Cepaitis  2:470/1     BEEMAIL
     FrontDoor APX  1.12     P S Mats Wallin       2:201/329   FDAPXW

     Windows (32-bit apps):
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     Argus 95       2.62     M S Max Masyutin      2:469/77    ARGUS95
     Argus NT       2.62     M S Max Masyutin      2:469/77    ARGUSNT
     Argus NT/IP    2.62     M S Max Masyutin      2:469/77    ARGUSIP
     BeeMail        1.0      M C Andrius Cepaitis  2:470/1     BEEMAIL
     Binkley Docs   2.60     M F Bob Juge          1:1/102     BDOC_260.ZIP
     BinkleyTerm    2.60     M F Bob Juge          1:1/102     BW32_260.ZIP
     CFRoute        0.92     O G C. Fernandez Sanz 2:341/70    CFR
     GoldED         2.50     O S Len Morgan        1:203/730   GEO
     GoldED Docs    2.50     O S Len Morgan        1:203/730   GEM
     Maximus        3.01     B P Tech              1:249/106   MAXN
     Msged/NT       4.10     O G Andrew Clarke     3:635/728   MSGED41W.ZIP
     PlatinumXpress 2.00     M C Gary Petersen     1:290/111   PXW-INFO
     T-Mail         2.599I   M S Ron Dwight        2:220/22    TMAILNT
     WinFOSSIL/95   1.12 r4  F S Bryan Woodruff    1:343/294   WNFOSSIL.ZIP
     WinFOSSIL/NT   1.0 beta F S Bryan Woodruff    1:343/294   NTFOSSIL.ZIP

     Unix:
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     ifmail         2.10     M G Eugene Crosser    2:293/2219  IFMAIL
     ifmail-tx      ...tx8.2 M G Pablo Saratxaga   2:293/2219  IFMAILTX
     ifmail-tx.rpm  ...tx8.2 M G Pablo Saratxaga   2:293/2219  IFMAILTX.RPM
     Msged          4.00     O G Paul Edwards      3:711/934   MSGED
     Tobruk         0.33     T G Paul Edwards      3:711/934   TOBRUK

     Amiga:
     FIDONEWS 14-23               Page 35                   9 Jun 1997


     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     CrashMail      1.23     T X Fredrik Bennison  2:205/324   CRASHMAIL
     CrashTick      1.1      O F Fredrik Bennison  2:205/324   CRASHTICK
     DLG Pro BBOS   1.15     B C Holly Sullivan    1:202/720   DLGDEMO
     GMS            1.1.85   M S Mirko Viviani     2:331/213   GMS
     Msged          4.00     O G Paul Edwards      3:711/934   MSGED
     Tobruk         0.33     T G Paul Edwards      3:711/934   TOBRUK

     TrapDoor       1.86.b2  M S Maximilian Hantsch
                                                   2:310/6     TRAPDOOR
     TrapDoor       1.86.b2  M S Maximilian Hantsch
                                                   2:310/6     TRAPBETA
     TrapToss       1.50     T S Rene Hexel        2:310/6     TRAPTOSS

     Atari:
     Program Name   Version  F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     ApplyList      1.00     N F Daniel Roesen     2:2432/1101 APLST100.LZH
     BinkleyTerm/ST 3.18pl2  M F Bill Scull        1:363/112   BINKLEY
     BTNC           2.00     N G Daniel Roesen     2:2432/1101 BTNC
     JetMail        0.99beta T S Joerg Spilker     2:2432/1101 JETMAIL
     Semper         0.80beta M S Jan Kriesten      2:2490/1624 SMP-BETA

     Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
               C-Compression, F-Fossil, O-Other. Note: Multifunction will
               be listed by the first match.

     Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
           X-Crippleware, D-Demoware, G-Free w/ Source

     Please send updates and suggestions to: Peter Popovich, 1:363/264

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 36                   9 Jun 1997


     =================================================================
                            FIDONEWS PUBLIC-KEY
     =================================================================


     [this must be copied out to a file starting at column 1 or
      it won't process under PGP as a valid public-key]


     -----BEGIN PGP PUBLIC KEY BLOCK-----
     Version: 2.6.2
     Comment: Clear-signing is Electronic Digital Authenticity!

     mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
     eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
     Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
     tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
     JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
     FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
     c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
     FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
     1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
     O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
     UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
     8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
     ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
     q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
     3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
     raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
     FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
     vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
     X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
     Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
     toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
     D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
     SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
     AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
     v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
     FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
     WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
     DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
     EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
     +Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
     Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
     aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
     ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
     =61OQ
     -----END PGP PUBLIC KEY BLOCK-----


     File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
     Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
     1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
     the FidoNews homepage listed in the Masthead information.

     -----------------------------------------------------------------
     FIDONEWS 14-23               Page 37                   9 Jun 1997


     =================================================================
                            FIDONET BY INTERNET
     =================================================================

     This is a list of all FidoNet-related sites reported to the Editor as
     of this appearance.

     ============

     FidoNet:

       Homepage     http://www.fidonet.org
       FidoNews     http://ddi.digital.net/~cbaker84/fidonews.html
       HTML FNews   http://www.geocities.com/Athens/6894/
       WWW sources  http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
       FTSC page    http://www2.blaze.net.au/ftsc.html
       Echomail     http://www.portal.ca/~awalker/index.html
       WebRing      http://ddi.digital.net/~cbaker84/fnetring.html

     ============

     Zone 1:       http://www.z1.fidonet.org

       Region 10:  http://www.psnw.com/~net205/region10.html

       Region 11:  http://oeonline.com/~garyg/region11/

       Region 13:  http://www.smalltalkband.com/st01000.htm

       Region 14:  http://www.netins.net/showcase/fidonet/

       Region 15:  http://www.smrtsys.com/region15/ [disappeared?]

       Region 16:  http://www.tiac.net/users/satins/region16.htm

       Region 17:  http://www.portal.ca/~awalker/region17.htm
           REC17:  http://www.westsound.com/ptmudge/

       Region 18:  http://www.citicom.com/fido.html

       Region 19:  http://www.compconn.net

     ============

     Zone 2:       http://www.z2.fidonet.org

     ZEC2:         http://fidoftp.paralex.co.uk/zec.htm [shut down?]
     Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm

       Region 20:  http://www.fidonet.pp.se (in Swedish)

       Region 24:  http://www.swb.de/personal/flop/gatebau.html (in German)

       Region 25:
                   http://members.aol.com/Net254/

     FIDONEWS 14-23               Page 38                   9 Jun 1997


       Region 27:  http://telematique.org/ft/r27.htm

       Region 29:  http://www.rtfm.be/fidonet/  (in French)

       Region 30:  http://www.fidonet.ch  (in Swiss)

       Region 34:  http://www.pobox.com/cnb/r34.htm  (in Spanish)
           REC34:  http://pobox.com/~chr

       Region 36:  http://www.geocities.com/SiliconValley/7207/

       Region 41:  http://www.fidonet.gr (in Greek and English)

       Region 48:  http://www.fidonet.org.pl

     ============

     Zone 3:       http://www.z3.fidonet.org

     ============

     Zone 4:       (not yet listed)

       Region 90:
         Net 904:  http://members.tripod.com/~net904 (in Spanish)

     ============

     Zone 5:       (not yet listed)

     ============

     Zone 6:       http://www.z6.fidonet.org

     ============

     -----------------------------------------------------------------

     FIDONEWS 14-23               Page 39                   9 Jun 1997


     =================================================================
                           FIDONEWS INFORMATION
     =================================================================

     ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

     Editor: Christopher Baker

     Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
                       Vince Perriello, Tim Pozar, Sylvia Maxwell,
                       Donald Tees

     "FidoNews Editor"
         FidoNet  1:1/23
         BBS  1-904-409-7040,  300/1200/2400/14400/V.32bis/HST(ds)

      more addresses:
         Christopher Baker -- 1:18/14, [e-mail]
                                       [e-mail]
                                       [e-mail]

     (Postal Service mailing address)
         FidoNews Editor
         P.O. Box 471
         Edgewater, FL 32132-0471
         U.S.A.


     voice:  1-904-409-3040 [1400-2100 ET only, please]
                            [1800-0100 UTC/GMT]

     ------------------------------------------------------

     FidoNews is published weekly by and for the members of the FIDONET
     INTERNATIONAL AMATEUR ELECTRONIC MAIL system.  It is a compilation
     of individual articles contributed by their authors or their
     authorized agents.  The contribution of articles to this compilation
     does not diminish the rights of the authors.  OPINIONS EXPRESSED in
     these articles ARE THOSE OF THE AUTHORS and not necessarily those of
     FidoNews.

     Authors retain copyright on individual works; otherwise FidoNews is
     Copyright 1997 Christopher Baker.  All rights reserved.  Duplication
     and/or distribution permitted for noncommercial purposes only.  For
     use in other circumstances, please contact the original authors, or
     the Editor.

                            =*=*=*=*=*=*=*=*=

     OBTAINING COPIES: The most recent issue of FidoNews in electronic
     form may be obtained from the FidoNews Editor via manual download or
     file-request, or from various sites in the FidoNet and Internet.
     PRINTED COPIES may be obtained by sending SASE to the above postal
     address.  File-request FIDONEWS for the current Issue.  File-request
     FNEWS for the current month in one archive.  Or file-request specific
     back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
     FIDONEWS 14-23               Page 40                   9 Jun 1997


     particular Issue.  Monthly Volumes are available as FNWSmmmy.ZIP
     where mmm = three letter month [JAN - DEC] and y = last digit of the
     current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.

     Annual volumes are available as FNEWSn.ZIP where n = the Volume number
     1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
     size from 48K to 1.4M.


     INTERNET USERS: FidoNews is available via:

                          http://www.fidonet.org/fidonews.htm
                          ftp://ftp.fidonet.org/pub/fidonet/fidonews/
                          ftp://ftp.aminet.org/pub/aminet/comm/fido/

                                      *=*=*

     You may obtain an email subscription to FidoNews by sending email to:

                          [e-mail]

     with a Subject line of: subscribe fnews-edist

     and no message in the message body. To remove your name from the email
     distribution use a Subject line of: unsubscribe fnews-edist with no
     message to the same address above.

                                      *=*=*

     You can read the current FidoNews Issue in HTML format at:

                          http://www.geocities.com/Athens/6894/

     STAR SOURCE for ALL Past Issues via FTP and file-request -
     Available for FReq from 1:396/1 or by anonymous FTP from:

                          ftp://ftp.sstar.com/fidonet/fnews/

     Each yearly archive also contains a listing of the Table-of-Contents
     for that year's issues.  The total set is currently about 11 Megs.

                                 =*=*=*=

     The current week's FidoNews and the FidoNews public-key are now also
     available almost immediately after publication on the Editor's new
     homepage on the World Wide Web at:

                  http://ddi.digital.net/~cbaker84/fidonews.html

     There are also links there to jim barchuk's HTML FidoNews source and
     to John Souvestre's FTP site for the archives. There is also an email
     link for sending in an article as message text. Drop on over.

                            =*=*=*=*=*=*=*=*=

     A PGP generated public-key is available for the FidoNews Editor from
     FIDONEWS 14-23               Page 41                   9 Jun 1997


     1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
     Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18.  It
     is also posted twice a month into the PKEY_DROP Echo available on the
     Zone 1 Echomail Backbone.

                                *=*=*=*=*

     SUBMISSIONS: You are encouraged to submit articles for publication in
     FidoNews. Article submission requirements are contained in the file
     ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
     from 1:1/23 [1:18/14] as file "ARTSPEC.DOC".  ALL Zone Coordinators
     also have copies of ARTSPEC.DOC. Please read it.

     "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
     trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
     and are used with permission.

             "Disagreement is actually necessary,
              or we'd all have to get in fights
              or something to amuse ourselves
              and create the requisite chaos."
                                -Tom Jennings

      -30-

     -----------------------------------------------------------------